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existing  operational  or  non-operational  infrastructure.  Wi-Fi  Direct  can  enable  such 
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for  first  responders.  An  extension  to  Wi-Fi  Direct  has  been  developed  that  would  address 
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I.  INTRODUCTION 


In  the  last  year,  we  witnessed  an  addition  of  497  million  mobile  deviees  to  the 
already  existing  6.9  billion  in  2013.  Altogether,  there  are  more  than  7.4  billion  mobile 
deviees  in  use  worldwide.  In  2014,  an  addition  of  439  million  smartphones  aeeounted  for 
an  88  pereent  of  the  total  growth  in  eellular  phones  [1].  The  aeeessibility  of  mobile 
deviees  has  revolutionized  the  way  people  use,  aeeess,  and  exehange  information. 

One  method  for  exehanging  information  over  these  deviees  is  through  the  use  of 
Wi-Fi  Direet  [2].  Wi-Fi  Direet  is  a  relatively  new  wireless  protoeol.  This  protoeol  allows 
for  Peer-to-Peer  (P2P)  mobile  Ad  Hoe  networking.  Wi-Fi  Direet  benefits  from  the 
strengths  of  the  Wi-Fi  standard — performanee,  seeurity,  and  ease  of  use — and  adds  a 
number  of  new  funetionalities.  These  added  funetionalities  inelude:  automatie  deviee 
diseovery,  a  mutual  awareness  of  eapabilities  between  deviees  (inter-deviee  eapability 
awareness),  sophistieated  power  management,  and  Infrastrueture-less  eonneetivity. 
Conneetions  between  these  deviees  ean  happen  anytime  and  anywhere.  When  deviees 
eome  within  range  of  one  another,  a  eonneetion  request  is  sent.  Upon  request  aeeeptanee, 
a  P2P  Group  is  established  and  eommunieation  is  enabled.  To  enable  eommunieation, 
one  of  the  deviees  assumes  the  role  of  P2P  Group  Owner  (Soft  Aeeess  Point)  while  the 
others  beeome  P2P  Clients.  However,  there  is  a  drawbaek  to  this  protoeol. 

A,  PROBLEM  AREA 

While  Wi-Fi  Direet  provides  many  useful  features  and  funetionality,  a  signifieant 
drawbaek  of  Wi-Fi  Direet  is  that  it  does  not  allow  the  transfer  of  the  Group  Owner  role. 
Upon  deviee  diseovery,  one  of  the  deviees  assumes  the  role  of  Group  Owner  (Soft 
Aeeess  Point).  This  role  eannot  be  transferred.  Therefore,  when  the  Group  Owner  leaves, 
the  network  eollapses.  There  are  two  methods  in  whieh  a  Group  Owner  ean  leave  the 
network.  In  the  standard  method,  a  user  must  manually  press  the  diseonneet  button.  Onee 
the  diseonneet  button  is  pressed,  the  Group  Owner  stops  assuming  the  role  of  a  software 
aeeess  point  and  eonneetivity  between  all  deviees  stops.  The  other  method  in  whieh  the 
Group  Owner  leaves  the  network  is  a  eatastrophie  failure  or  loss  of  power  to  the  deviee. 


1 


In  this  case,  the  network  gets  destroyed  and  eonneetivity  between  all  the  deviees  stops.  In 
either  ease,  once  the  Group  Owner  leaves,  a  permanent  interruption  to  the  network  oeeurs 
and  all  eommunieation  between  devices  eeases  [3]. 

B,  OBJECTIVE 

An  extension  is  proposed  to  extend  the  Wi-Fi  Direct  protocol  to  prevent  the 
network  from  eollapsing  when  the  Group  Owner  has  to  ehange.  This  would  allow  for  a 
more  persistent  network  using  Wi-Fi  Direet. 

There  are  many  seenarios,  sueh  as  Humanitarian  Assistance  and  Disaster  Relief 
(HA/DR)  operations,  disconneeted  military  small  unit  operations,  and  other  situations 
involving  people  disconneeted  from  the  Internet,  where  this  extended  protoeol  would 
have  a  signifieant  and  large  impaet  [3]. 

C,  METHODOLOGY 

A  detailed  review  of  the  Wi-Fi  Direet  protoeol  will  be  eompleted  before 
developing  sehemes  to  extend  the  protoeol.  The  foeus  will  be  on  how  group  ownership 
gets  established  and  how  groups  in  general  are  formed.  There  will  also  be  a  eomparison 
of  other  teehnologies  that  are  used  to  exehange  information  wirelessly.  A  diseussion 
illustrating  the  importanee  of  new  protoeol  using  a  HA/DR  operation  use  ease  is  provided 
as  the  basis  for  eomparing  alternate  schemes.  A  suitable  approaeh  for  transferring  group 
ownership  will  be  seleeted  for  implementation.  The  next  step  will  be  to  implement  the 
determined  approaeh.  Once  implementation  has  been  eompleted,  lab  testing  will  be 
eonducted. 

D,  THESIS  STRUCTURE 

The  strueture  of  this  thesis  is  as  follows: 

Chapter  II  provides  the  baekground  for  the  work.  This  ineludes  an  overview  of 
Wi-Fi  802.11,  Wi-Fi  Direet  and  Bluetooth.  A  comparison  of  these  teehnologies  is 
provided.  A  discussion  of  a  use  ease  for  the  extended  Wi-Fi  Direet  protoeol  is  also 
eovered. 
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Chapter  III  covers  the  design  and  protocol  extension.  Several  possible  protocol 
extensions  are  considered.  The  recommended  approach  will  be  selected.  This  chapter  also 
describes  the  design  and  model  of  the  extended  protocol. 

Chapter  IV  describes  the  implementation  and  testing.  Implementation  is  done 
using  several  mobile  devices.  All  of  the  testing  is  conducted  in  a  laboratory  environment. 

To  conclude,  Chapter  V  summarizes  the  work  and  provides  recommendations  for 
future  research. 
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II.  BACKGROUND 


This  chapter  covers  specifications  of  Wi-Fi,  Wi-Fi  Direct  and  Bluetooth.  Also  a 
comparison  between  each  of  these  protocols  is  provided.  In  addition,  a  use  case  for  the 
extended  Wi-Fi  direct  is  discussed.  The  emphasis  is  on  the  different  types  of  wireless 
technologies  and  how  each  works. 

A,  WIRELESS  TECHNOLOGY 

Wireless  technology  has  revolutionized  how  information  is  exchanged  between 
people,  and  more  specifically  devices.  Prior  to  the  advent  of  the  wireless  technology,  all 
information  exchanges  were  made  using  physical,  wired  connections.  Wireless 
technology  has  allowed  for  greater  mobility,  which  has  allowed  for  innovative  solutions 
to  everyday  problems.  We  are  now  able  to  receive  and  exchange  information  freely  in 
almost  any  place  and  at  any  time.  Technologies  that  have  enabled  this  exchange  of 
information  include  Wi-Fi,  Wi-Fi  Direct  and  Bluetooth. 

B,  WI-FI 

Wi-Fi — Wireless  Fidelity — is  based  on  the  IEEE  802.11  standard.  The  most 
common  use  of  Wi-Ei  is  for  Internet  connectivity  in  a  local  area  network  (LAN).  A 
wireless  LAN,  which  has  a  radius  of  tens  of  meters,  consists  of  wireless  devices  that 
transmit  and  receive  packets  to  and  from  a  base  station.  A  base  station  in  Wi-Ei  is  also 
commonly  known  as  an  Access  Point  (AP). 

1.  Architecture 

In  Wi-Ei,  a  basic  service  set  (BSS)  is  the  fundamental  building  block  of  a  wireless 
LAN.  A  BSS  can  have  one  or  more  wireless  devices  and  a  central  base  station.  Just  like  any 
Ethernet  device,  a  wireless  device  has  a  6-byte  MAC  (Medium  Access  Control)  address  that 
is  stored  in  the  firmware  of  its  NIC  (Network  Interface  Card).  So  the  APs  wireless  interface 
will  also  have  a  MAC  Address.  IEEE  manages  the  distribution  of  MAC  addresses,  and  each 
is  globally  unique.  Wireless  LANs  require  infrastructure  and  are  sometimes  referred  to  as 
infrastructure  wireless  LANs  [4].  Eigure  1  illustrates  a  basic  wireless  LAN. 
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Client  1 


Client  2  Client  3 

Figure  1.  Illustrates  a  Basic  Wireless  LAN,  from  [5] 

2,  Access  Point 

In  a  wireless  network,  an  AP  is  the  key  element  of  the  infrastructure.  The  AP  is 
responsible  for  sending  and  receiving  data  between  clients.  It  also  manages  the 
coordination  of  multiple  clients  transmitting.  Hotspots  are  used  for  Internet  connectivity 
via  mobile  devices  and  cell  service  providers.  An  AP  establishes  communication  by  the 
use  of  scanning.  An  AP  can  perform  two  types  of  scans.  The  first  type  is  when  it  scans 
for  channels  and  listens  for  beacon  frames.  This  type  of  scanning  is  referred  to  as  passive 
scanning.  The  other  type  of  scanning  is  known  as  active  scanning.  Active  scanning  is 
accomplished  by  broadcasting  a  probe  frame  to  be  received  by  any  AP  within  its  wireless 
range.  In  passive  scanning,  the  first  step  is  for  a  beacon  frame  to  be  sent  out  from  the  AP. 
Then  the  next  step  is  for  an  association  request  to  be  sent  from  the  client  to  the  AP.  In  the 
final  step,  an  association  response  is  sent  from  the  AP  to  the  client.  For  active  scanning, 
the  initial  step  is  a  probe  request  frame  that  gets  broadcasted  to  all  AP.  Then  each  AP  will 
send  a  probe  response.  Followed  by  an  association  request  frame  sent  from  the  client  to 
every  AP.  To  conclude,  an  association  response  is  sent  by  all  AP  to  the  client  [6]. 
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3. 


Standards 


There  are  multiple  standards  of  802.1 1,  which  ciineutly  include  802.1  la,  802.1  lb, 
802.1  Ig,  802.1  In  and  802.1  lac.  Tliere  are  some  devices  that  can  operate  in  dual  mode 
(for  example,  802.11a  and802.11g)  or  hi  mode  (for  example,  802.11a,  802.11b  and 
802.1  Ig).  Table  1  illustrates  each  standards  frequency  range  and  data  rate. 


Standard 

Frequency 

Range 

Data 

Rate 

802.11a 

5.1-5.8  GHz 

Up  to 

11Mbps 

802.11b 

2.4-2.485  GHz 

Up  to  54 
Mbps 

802.11g 

2.4-2.485  GHz 

Up  to  54 
Mbps 

802.1  In 

2.412-2.484  GHz 

Up  to 

300Mbps 

802.1  In 

5.180  -5.809  GHz 

Up  to  300 
Mbps 

Table  1.  Illustrates  Each  Standards  Frequency  and  Data  Rate,  after  [6] 


C.  \M-FI  DIRECT 

Wi-Fi  Dhect  benefits  fiom  the  strengths  of  the  standard  Wi-Fi,  which  include 
peiToiinance,  security,  and  ease  of  use,  and  adds  a  number  of  new  ftmctionalities.  These 
new  ftmctionalities  include;  automatic  device  discovery,  a  muhial  awareness  of 
capabilities  between  devices  (inter-device  capability  awareness),  sophisticated  power 
management,  and  infiastnrchue  requirement.  Cormections  between  these  devices  can 
happen  anytime  and  anywhere,  allowmg  for  device-to-device  conmimrication.  P2P 
devices  sirpport  both  Groirp  owner  (GO)  and  Client  roles.  These  devices  negotiate  to 
establish  Groirp  Owner  and  client  roles.  Group  Owners  are  essentially  software  APs. 
They  can  provide  communication  between  clients  and  access  to  a  concmient  WLAN 
cormection. 
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1,  Topology 

The  topology  for  Wi-Fi  Direct  can  be  one  to  many,  such  that  several  clients  can 
be  connected  to  one  Group  Owner  The  set  of  connected  devices  is  known  as  a  P2P 
group.  Figure  2  shows  a  one-to-many  relationship.  The  topology  can  also  be  one-to-one 
as  depicted  in  Figure  3. 


Figure  2  One-to-Many  Relationship  Group  Owner  Is  Connected  between 
Two  Devices  and  Is  Acting  as  the  Software  AP,  from  [3] 


P2P  Group 
Owner 


Client 


1:1  P2P  Group 


Figure  3.  One-to-One  Relationship,  from  [3] 


A  P2P  device  can  operate  simultaneously  with  a  WLAN  (see  Figure  4).  That 
device  is  known  as  a  P2P  concurrent  device  Any  device  performing  concurrent 
operations  requires  multiple  MAC  entities.  A  concurrent  operations  device  can  operate  on 
the  same  or  different  class  and  channel  as  a  P2P  group.  For  example,  P2P  may  operate  on 
channel  6  in  the  2.4  GHz  band,  while  the  WLAN  BSS  can  operate  on  channel  36  in  the 
5.8  GHz  band.  Concurrent  operations  are  depicted  in  Figure  4. 
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Figure  4.  Simultaneous  Connection  to  a  P2P  Device  and  a  Wireless  AP, 

from  [3] 


2.  Device  Discovery 

Device  discovery  enables  P2P  devices  arriving  on  the  same  channel  to  exchange 
device  information.  The  purpose  of  the  P2P  device  discovery  is  to  rapidly  determine 
which  devices  will  attempt  a  connection.  Device  Discovery  is  made  up  of  three  major 
phases:  Listen,  Scan  and  Find. 

In  the  listen  phase,  a  device  that  is  not  in  a  P2P  group  can  become  discoverable. 
There  are  3  predetermined  listen  channels.  These  channels,  also  known  as  social 
channels,  are  1,  6  and  1 1  in  the  2.4  GHz  band. 

P2P  devices  use  the  scan  phase  to  locate  the  best  operating  channel  for  group 
formation  and  to  find  other  P2P  devices  and  Groups.  By  scanning  all  supported  channels, 
devices  in  the  scan  phase  collect  information  about  surrounding  devices  and  networks.  A 
device  can  limit  its  scan  to  specific  P2P  devices  or  Groups.  For  devices,  the  limitation 
can  be  to  specific  device  types. 

The  find  phase  is  used  to  enable  communication  by  ensuring  that  two  P2P  devices 
searching  at  the  same  time  arrive  to  a  common  channel.  This  is  accomplished  by  cycling 
between  states.  Randomizing  the  time  spent  on  each  cycle  of  the  listen  state  enables 
convergence  of  two  devices  on  the  same  channel.  Limiting  the  list  of  channels  to  the 
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social  channels  minimizes  the  eonvergenee  time.  Figure  5  illustrates  the  device  diseovery 
proeedures. 


SME^Applicationy 
UserA/endor  1 


P2P  Device  1 


P2P  Device  2 


SME/Application/ 
User/Vendor  2 


Discover  other 
P2P  Devices 
Optional  WSC 
Provisioning  Command 


Listen  State  for  N 
intervals  of  lOOTUs. 
N  is  random. 


Discover  other 
P2P  Devices 
Optional  WSC 
Provisionir>g  Command 
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□ 
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listen 


search 


Notify  that  P2P 
Device  found 


Probe  Request  (P2P  IE.  WSC  IE, 

RSN  IE.  Supported  Regulatory  IE)  ^ 

Probe  Request  (P2P  IE,  WSC  IE.  RSN 
IE,  Supported  Regulatory  IE) 

_ Probe  Response  (P2P  IE,  WSC  IE.  RSN  IE, 

Supported  Regulatory  Class  IE) 

Probe  Request  (P2P  IE,  WSC  IE. 

RSN  IE.  Supported  Regulatory  IE)  ** 


listen 


Figure  5.  Device  Discovery  Procedures  for  a  P2P  Device,  from  [3] 

3.  Invitation  Procedure 

The  invitation  procedure  is  used  in  three  cases:  when  a  device  receives  an 
invitation  by  a  Group  Owner  to  become  a  client  in  the  group,  when  a  client  invites 
another  device  to  become  part  of  their  existing  group,  and  when  a  Group  Owner  chooses 
to  invoke  a  P2P  Persistent  Group. 

a.  Invitation  Request 

A  Group  Owner  or  a  client  can  send  out  an  Invitation  Request.  When  the  Group 

Owner  sends  out  an  invitation  request,  it  contains  the  Group  ID,  Group  BSSID,  Channel 
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List,  Operating  Channel  and  Configuration  Timeout  Attributes.  A  request  that  is  sent  by  a 
elient  will  eontain  the  Group  ID,  Group  BSSID  and  Configuration  Timeout  Attributes. 

b.  Invitation  Response 

A  deviee  that  reeeives  an  Invitation  Request  will  respond  by  sending  an  Invitation 
Response.  A  Response  sent  by  a  Group  Owner  will  eontain.  Group  BSSID,  Channel  List, 
Potential  Operating  Channels,  Indented  Operating  Channel,  Configuration  Timeout 
Attributes  and  the  Group  Owner  Configuration  Time.  An  invited  elient  will  respond  by 
sending  a  response  that  eontains  the  Channel  List  and  Configuration  Timeout  Attributes. 
All  supported  Operating  Channels  will  be  indieated  on  the  Channel  List.  Only  Channels 
indieated  on  the  Channel  List  from  the  Invitation  Request  will  be  on  the  Invitation 
Response  Channel  List.  Configuration  time  will  be  indieated  in  the  Configuration 
Timeout  attribute,  whieh  will  inelude  the  point  that  the  elient  is  ready  to  join  the  group 
until  after  the  Invitation  Response  indieates  a  sueeess. 

c.  Group  Owner  Negotiation 

The  Group  Owner  Negotiation  happens  through  a  three-way  handshake.  When  a 
device  comes  within  range  of  another  device,  it  sends  a  Group  Owner  negotiation 
request.  In  the  request  there  is  a  Group  Owner  intent  field.  In  this  field  the  device  can  set 
a  value  of  0  to  15.  Devices  that  require  Group  Ownership  in  order  to  work  properly  will 
set  a  value  of  15.  Those  devices  that  do  not  require  being  a  Group  Owner  will  have  a 
lesser  value.  The  second  device  will  then  send  a  Group  Owner  negotiation  response  with 
its  own  Group  Owner  intent.  If  there  is  a  tie  between  the  two  devices,  the  Group  Owner 
will  be  determined  by  the  tiebreaker  bit.  The  tiebreaker  bit  gets  set  randomly  when  each 
device  gets  powered  on.  The  bit  consist  of  I  or  a  0,  the  device  that  has  a  value  of  I  will 
become  the  Group  Owner.  The  network  gets  established  when  the  first  device  sends  a 
Group  Owner  negotiation  confirmation.  One  device  becomes  the  Group  Owner  while  the 
others  become  P2P  Clients.  Figure  6  illustrates  the  Group  Owner  Negotiation.  Group 
Owner  determination  is  illustrated  in  Figure  7. 


II 


P2P  Device 


P2P  Device 


GO  Negotiation  Request 

(The  P2P  IE  Includes  P2P  Capabilily.  P2P  Device  Info,  Group 
Owner  Intent,  Configuration  Timeout,  Listen  Channel,  Extended  Listen  Timing, 
Intended  P2P  Interface  Address,  Channel  List,  and  Operating  Channel  attributes 
The  WSC  IE  includes  Device  Password  ID  attribute) 


GO  Negotiation  Response 
(The  P2P  IE  includes  P2P  Capabilit/.  P2P  Device  Info,  Group 
Owner  Intent,  Configuration  Timeout.  Intended  P2P  Interface  Address, 

Channel  List,  and  Operating  Channel  attributes.  The  WSC  IE  includes  Device  Password  ID  attribute) 


GO  Negotiation  Confirmation 

(The  P2P  IE  includes  P2P  Capability,  Status,  Channel  List, 
and  Operating  Channel  attributes) 


Figiue  6.  Group  Owner  Negotiation,  from  [3] 


x1  =  Group  Owner  Intent  Value  of  P2P  Device  1 
x2  =  Group  Owner  Intent  Value  of  P2P  Device  2 


I 

Fail.  Both  P2P  Devices 
want  to  become  Group 
Owner 


Figiue  7.  Gioup  Owner  Intent  Negotiation,  fr  om  [3] 


4.  Invoking  a  P2P  Persistent  Group 

Once  a  device  successfrilly  obtains  credentials  from  a  gioup,  it  stores  the  P2P 
Group  ID  and  Credentials  for  that  group.  This  allows  the  Group  Owner  to  recreate  a 
session  at  any  time  after  the  initial  formation.  Clients  can  also  use  the  stored  credentials 
to  request  a  Persistent  Group  be  started.  The  Group  Owner  has  the  option  of  maintaining 
a  list  of  device  addresses  that  have  joined  the  Persistent  group.  For  each  session,  the 
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Group  ID  and  Credentials  will  not  change,  although  the  interface  address  and  operating 
channel  can  change  for  each  session  [3]. 

D.  WI-FI  HOTSPOTS 

A  Wi-Fi  Hotspot  or  tethering  is  a  method  for  accessing  the  Internet  via  a  mobile 
phone.  This  method  enables  a  mobile  phone  to  use  its  cellular  connection  to  provide 
access  to  the  Internet.  A  mobile  device  can  connect  to  a  mobile  phone  through  Wi-Fi. 
Almost  all  devices  in  the  United  States  can  support  up  to  5  devices  being  tethered  to  one 
mobile  phone.  While  at  the  surface  level  there  may  seem  a  lot  of  similarities  between  Wi¬ 
Fi  Direct  and  Wi-Fi  Hotspots,  the  two  technologies  are  quite  different.  Wi-Fi  Hotspots 
require  physical  infrastructure  to  work.  The  infrastructure  is  the  cellular  infrastructure 
that  provides  access  to  the  Internet.  In  addition,  the  AP  functionality  supported  by  the 
Wi-Fi  Hotspot  phone  does  not  go  through  the  process  of  Group  Owner  negotiations  as  the 
device  that  creates  the  AP  is  the  equivalent  of  a  Group  Owner.  Wi-Fi  Hotspot  set-up  also 
does  not  support  the  advanced  power  management  features  supported  by  Wi-Fi  Direct. 

E,  BLUETOOTH 

Bluetooth  is  another  technology  that  allows  devices  to  communicate  wirelessly  in 
ad-hoc  networking  modes.  The  main  features  of  Bluetooth  consist  of  it  being  low  power 
and  low  cost.  Almost  all  mobile  devices  in  the  U.S.  are  equipped  with  Bluetooth.  Paring 
is  when  two  Bluetooth  enabled  devices  connect  to  each  other.  In  order  for  these  devices 
to  pair,  they  need  to  be  in  proximity  of  one  another.  Establishing  a  connection  allows  the 
two  devices  to  share  information  wirelessly.  These  networks  are  established 
automatically  and  dynamically  as  devices  come  within  range  of  one  another.  Bluetooth 
has  the  ability  to  transmit  voice  and  data  simultaneously.  Bluetooth  operates  in  the  2.4  to 
2.48GHz  unlicensed  industrial,  scientific  and  medical  (ISM)  band.  There  are  3  Classes  of 
Bluetooth  radios.  Class  3,  Class  2  and  Class  1.  Class  2  radios  are  found  in  mobile 
devices.  They  have  a  range  of  about  10  meters  or  33  feet  [7]. 
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1,  Connectivity 


A  Bluetooth  network  is  known  as  a  piconet.  A  piconet  is  a  set  of  at  most  seven 
devices;  a  single  device  controls  each  piconet.  The  six  other  non-controlling  devices  can 
be  connected  to  other  piconets  simultaneous  as  well.  A  group  of  piconets  is  known  as  a 
scattemet  (Figure  8).  The  piconets  do  not  need  to  be  interconnected  in  the  scattemet,  but 
can  be.  The  controlling  device  is  called  a  master.  The  device  that  accepts  the  request 
becomes  the  slave.  The  master  controls  the  channel  and  all  the  slaves  operating  on  that 
channel.  All  Bluetooth  devices  are  identical  except  for  a  unique  48-bit  device  identifier 
[8].  The  symbol  m  indicates  a  device  is  a  master,  and  the  symbol  s  indicates  a  device  is  a 
slave. 


Piconet  C 

Figure  8.  Piconets  Making  up  a  Scattemet,  from  [9] 


2,  States 

The  two  main  states  for  Bluetooth  are  Standby  and  Connection.  There  are  seven 
other  interim  states  that  are  used  to  add  new  slave  devices  to  a  piconet.  The  seven  other 
states  are  Inquiry,  Inquiry  Scan,  Inquiry  Response,  Page  Scan,  Page,  Slave  Response  and 
Master  Response. 


14 


a.  Standby 

When  a  device  initially  powers  up  Bluetooth,  it  will  be  in  the  default  state,  which 
is  called  the  standby  state.  If  this  same  device  sends  a  connection  request  and  it  receives  a 
reply  from  another  device,  then  it  will  immediately  transition  into  the  connection  state  as 
a  master.  Otherwise,  if  the  device  receives  a  connection  request  and  replies  with  an 
acknowledgement,  it  will  immediately  enter  the  connection  state  as  a  slave. 

b.  Inquiry,  Inquiry  Scan,  Inquiry  Response 

The  purpose  for  the  Inquiry  set  of  states  is  to  allow  a  device  to  determine  which 
devices  are  available  within  transmit  and  receive  range.  A  device  uses  Inquiry  Scan  to 
scan  on  a  frequency.  In  the  Inquiry  state,  a  device  can  query  another  device  that  is  in  the 
Inquiry  Scan  state.  A  Connection  state  cannot  be  reached  from  an  Inquiry  state.  The 
purpose  of  Inquiry  Respond  state  is  to  transition  out  of  the  Inquiry  Scan  state.  This  is 
accomplished  by  a  device  in  the  Inquiry  scan  state,  responding  to  a  request  from  a  device 
in  the  Inquiry  state. 

c.  Page  Scan  State 

The  Page  Scan  state  can  be  entered  from  the  Standby  or  Connection  states  and 
scans  a  single  hop  frequency,  1 1.25ms.  In  order  for  a  device  to  enter  the  Page  Scan  State 
from  a  Connection  State,  it  must  free  up  as  much  available  scan  time  as  possible.  The 
Bluetooth  device’s  address  determines  the  scan  frequency. 

d.  Page  State 

When  a  device  establishes  a  connection  with  a  slave  device,  this  state  is  known  as 
the  Page  State.  In  this  case,  the  master  device  determines  what  frequency  to  transmit  the 
page  on. 


e.  Slave  Response/Master  Response  State 

An  initial  Packet  ID  is  sent  from  the  Master  to  the  slave.  Then  the  Slave  will 
respond  with  its  own  Packet  ID.  Followed  by  the  Master  sending  a  Frequency  Hoping 
Synchronization  (FHS)  and  the  Slave  responding  with  an  acknowledgment  of  the  Packet 
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ID.  To  conclude,  after  a  sueeessful  exehange  of  information  both  deviees  ean  start 
eommunieating  with  eaeh  other. 


Master  Slave 


Figure  9.  The  Process  by  Whieh  Messages  and  States  Progress  as  a  Page 

Request  Is  Serviced,  from  [8] 


f.  Connection  State 

This  is  the  state  where  the  master  and  slave  deviees  exehange  information.  In 
order  for  the  master  deviee  to  determine  if  the  slave  deviee  is  using  the  eorreet  frequeney- 
hopping  seheme,  and  that  the  eloeks  are  synehronized,  the  master  will  send  the  slave  a 
POLL  request.  If  the  slave  does  not  reeeive  the  POLL  request  or  if  the  master  does  not 
receive  a  response  then  both  devices  will  return  to  the  Page/Page  Sean  state.  The 
Connection  state  is  terminated  through  a  “reset”  or  “detaeh”  command.  The  link 
parameters  are  maintained  when  a  termination  is  exeeuted  through  the  “detach” 
command.  When  the  reset  command  is  executed,  all  existing  configuration  information 
gets  eliminated. 

3,  Service  Discovery 

Service  Discovery  is  an  optional  frame  exchange  that  can  be  done  with  any 
discovered  devices.  This  exchange  is  done  prior  to  any  group  formation  and  is  done  for 
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the  purposes  of  verifying  eompatibility  of  serviees  offered  between  each  device.  This 
service  is  adaptable  and  extendable  to  allow  higher  layer  service  protocols  such  as  Plug 
and  Play.  The  Service  Discovery  is  used  to  find  the  following:  all  services  offered  by  a 
device,  information  about  a  specific  service  offered  by  a  device,  information  about 
various  services  offered  by  a  device,  and  if  a  change  has  occurred  in  the  services  that  a 
device  offers.  A  Service  Discovery  Query  initiates  Service  Discovery. 

F.  COMPARISON 

Each  of  the  wireless  technologies  described  above  have  many  attributes  that  are 
common  while  others  are  different.  While  each  has  its  advantages  and  disadvantages,  a 
particular  technology  can  clearly  serve  as  an  optimal  solution  for  several  a  select  set  of 
use  cases. 

1,  Wi-Fi  versus  Wi-Fi  Direct 

Wi-Fi  and  Wi-Fi  Direct  are  very  similar  when  it  comes  to  functionalities  and 

capabilities.  However,  there  are  some  major  differences.  Both  of  these  protocols  allow 
for  the  wireless  exchange  of  information  between  devices.  While  Wi-Fi  has  been  around 
since  the  1990s,  Wi-Fi  Direct  has  come  into  existence  since  2010. 

a.  Similarities 

Both  technologies  can  operate  in  the  same  ISM  frequency  band  of  2.4  GHz.  They 
also  have  the  same  range  and  data  throughput.  Furthermore,  they  use  a  base  station-client 
model  where  one  device  acts  as  a  base  station  and  the  other  devices  are  clients. 

b.  Differences 

Wi-Fi  is  completely  dependent  on  infrastructure,  meaning  that  an  AP  (hardware) 
is  required  in  order  for  this  protocol  to  work.  Wi-Fi  Direct,  on  the  other  hand,  requires  no 
infrastructure  allowing  for  mobile  ad-hoc  networks  to  be  created  anywhere  and  anytime. 
It  utilizes  a  software  AP,  meaning  any  device  can  act  as  an  AP.  Not  depending  on 
infrastructure  increases  the  mobility  of  Wi-Fi  Direct.  Devices  utilizing  Wi-Fi  Direct  can 
also  simultaneously  use  Wi-Fi.  This  would  be  extremely  useful  in  environments  where 
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you  have  limited  infra stractiue.  In  addition,  Wi-Fi  Direct  has  a  power  management 
featiue  that  is  used  to  conserve  batteiy  power  on  all  devices  including  clients  and  APs. 
This  featiue  is  very  usefril  m  envuonments  where  the  ability  to  charge  mobile  devices 
might  be  lunited.  While  both  technologies  can  operate  in  the  same  2.4GHz  ISM  band, 
Wi-Fi  has  the  ability  to  operate  in  the  5.8GHz  band  as  well. 

2.  Wi-Fi  Direct  versus  Bluetooth 

Both  technologies  are  very  similar  with  some  differences.  They  both  allow  for  the 
wheless  exchange  of  infoimation.  Also,  both  of  them  can  be  used  for  mobile  ad-hoc 
networks. 


a.  Similarities 

Bluetooth  and  Wi-Fi  Direct  do  not  requue  any  infrashnctiue  in  order  to  work. 
This  allows  for  either  to  set  up  a  mobile  ad-hoc  network  anytime  and  anywhere.  Both  of 
these  technologies  requue  one  device  to  act  as  a  Gioup  Owner  or  Master  device,  while 
the  other  devices  in  the  network  become  Clients  or  Slaves.  Fmtheimore,  they  both 
operate  m  the  ISM  band. 

b.  Differences 

Bluetooth  is  limited  to  seven  devices  being  connected  in  a  piconet  (Bluetooth 
network).  Wi-Fi  Direct  does  not  have  the  same  limitation.  Bluetooth  is  also  limited  to  a 
range  of  10  meters  (33  feet)  whereas  Wi-Fi  Duect  has  a  range  of  about  100  meters. 
Bluetooth  limitations  can  prove  to  be  veiy  constiaining  in  certain  environments, 
specifically,  where  you  requue  more  than  7  devices  and  a  range  greater  than  10  meters. 

G.  EXTENDED  WI-FI  DIRECT  USE  CASE 

An  impactful  use  case  would  be  the  use  of  this  protocol  by  first  responders  in  a 
HA/DR  environment.  Ciuiently  commimication  between  mobile  devices  relies  on  local 
and  physical  iufrastmctiue.  First  responders  cannot  rely  on  the  availability  of 
infrastiuctiue  while  m  disaster  areas,  or  even  on  that  infrastiuctiue  to  work.  That  said, 
first  responders  equipped  with  mobile  devices  that  include  the  extended  Wi-Fi  Duect 
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could  rapidly  establish  a  mobile  ad-hoe  eommunieations  network.  This  network  would 
allow  information  exchange  between  government,  NGO’s  and  civilian  responders. 

1.  Hurricane  Katrina 

In  2005  Hurrieane  Katrina  had  a  devastating  impaet  on  the  Gulf  Coast.  It  is 
estimated  when  Katrina  made  landfall,  it  was  a  Category  3  Hurricane  (Winds  of  1 1 1-113 
MPH)  with  sustained  winds  of  125  MPH.  The  foree  of  these  winds,  along  with  storm 
surges  and  flooding,  damaged  or  destroyed  the  eommunieations  infrastrueture. 

Communications  infrastructure  was  one  of  the  most  affeeted  oritieal  seetors  by 
Hurrieane  Katrina.  Commereial  power  failed  and  foreed  180  eentral  offiee  loeations  to 
run  on  generators.  An  estimated  100  eommereial  radio  station  towers  were  taken  off  the 
air.  Land  Mobile  radio  was  greatly  degraded,  and  as  many  as  2000  eell  towers  were  taken 
out.  Most  of  the  baekbone  eonduit  that  supported  landline  serviees  was  flooded.  Not  ah 
communications  were  taken  out  by  the  storm  though.  For  example,  satellite  phones  eould 
be  used  onee  the  storm  passed,  but  there  were  very  few  to  go  around.  Eventually,  the 
satellite  phones  ran  out  of  battery  power  [10]. 

2,  Hurricane  Sandy 

In  2005  Hurricane  Sandy  made  landfall  in  the  northeastern  part  of  the  United 
States.  It  was  a  category  I  hurricane  with  sustained  winds  of  80  to  90  MPH.  Although  this 
hurricane  was  not  as  severe  as  Katrina,  it  still  had  a  significant  impact  on  the 
communications  infrastructure. 

It  was  estimated  that  about  25  percent  of  cellular  base  stations  in  the  affected  area 
lost  service.  Most  base  stations’  loss  of  service  was  due  to  lack  of  power.  Direct  damage, 
flooding  and  power  outages  directly  affected  wireline  telephony  outside  plant  equipment. 
Internet  has  become  a  vital  need  during  disasters.  During  Hurricane  Sandy  several  data 
centers  experienced  issues  and  loss  of  service  [11]. 
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3,  Summary  of  Use  Cases 

A  persistent  network  that  requires  no  infrastrueture  would  faeilitate  sharing  of 
information  in  a  disaster  area.  Wi-Fi  Direet  inereases  mobility  and  portability  by  allowing 
devices  to  connect  anywhere  and  anytime.  Extending  Wi-Fi  Direct  will  establish  a 
persistent  network  for  sharing  information. 
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III.  EXTENDED  WI-FI  DIRECT  DESIGN  AND  MODEL 


In  this  chapter  we  will  eover  the  two  proposed  solutions  for  the  extended  Wi-Fi 
Direet  design.  The  best  solution  will  be  chosen  and  a  model  of  it  will  be  given.  The 
model  will  be  represented  using  a  Deterministic  Finite  Automaton. 

A,  PROTOCOL  EXTENSION 

A  consideration  of  two  methods  for  extending  the  Wi-Fi  Direet  protocol  will  be 
performed.  The  two  methods  will  recommend  different  approaches  for  extending  the 
standard  Wi-Fi  Direet  protoeol.  More  speeifically  preventing  a  permanent  network 
disruption  when  an  existing  Group  Owner  leaves  the  group.  The  first  is  to  simply  make  a 
back  up  of  the  Group  Owner.  Once  a  back  up  is  made,  a  transition  of  group  ownership 
will  oecur  when  the  existing  Group  Owner  leaves.  The  other  is  to  make  a  persistent 
protocol  by  fully  automating  Wi-Fi  Direct.  This  will  automate  everything  from 
establishing  Wi-Fi  Direet  groups  to  the  migration  of  Group  Owners. 

1,  Back  Up  Group  Owner  Approach 

The  first  solution  involves  making  a  back  up  of  the  key  attributes  and 

eonfiguration  of  the  Group  Owner.  When  the  Group  owner  is  no  longer  present,  the 

designated  device  would  take  its  place.  In  this  approaeh,  we  deeided  that  the  first  device 

that  connected  to  the  Group  Owner  would  assume  the  role  of  back  up.  When  the  Group 

Owner  leaves,  the  designated  device  assumes  the  role  of  the  new  Group  Owner.  There 

were  many  details  that  had  to  be  kept  track  of  in  order  for  this  solution  to  work.  Among 

many  of  the  details,  the  most  important  were;  the  Group  Owner’s  IP  address,  device 

name,  and  mae  address  The  Group  Owner  IP  is  not  given  in  the  standard  protocol.  In 

order  for  us  to  find  the  IP  address,  we  had  to  create  a  method  that  would  give  it  to  us.  The 

device  name  and  mac  address  are  given  in  the  standard  protoeol  and  those  were  simply 

eopied.  Cheeking  for  a  constant  can  monitor  the  Group  Owner’s  connectivity.  This 

constant  informs  the  devices  in  the  network  whether  they  are  eonnected  to  the  Group 

Owner.  The  diffieulty  with  this  solution  is  foreing  a  deviee  to  be  a  copy  of  the  Group 

Owner.  The  back  up  device  would  have  to  have  the  same  IP,  device  name,  and  mae 
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address  in  order  for  this  solution  to  work.  Another  issue  is  what  happens  when  the  old 
Group  Owner  tries  to  re-join  the  network.  This  eauses  an  IP  conflict  because  there  are 
two  devices  with  the  same  IP.  Not  to  mention,  you  wouldn’t  be  able  to  ensure  proper 
routing  with  two  identical  devices.  The  biggest  issue  is  a  device  can  only  monitor  when  a 
Group  Owner  is  disconnected.  Which  means,  a  device  only  knows  when  the  network  has 
collapsed  completely.  Once  the  network  has  collapsed,  re-establishing  of  the  network 
must  be  done  with  the  back  up  Group  Owner.  Rather  than  keeping  track  of  all  the  details; 
a  more  streamline  approach  was  developed.  Figure  10  illustrates  what  the  initial  stage  in 
the  back  up  Group  Owner  model  would  look  like.  Figure  1 1  shows  what  would  happen 
after  the  Group  Owner  has  left  and  the  back  up  has  replaced  it. 


Group  Owner 


Back  Up 
Group  Owner 


Client 


Figure  10.  The  First  Iteration  of  the  Back  Up  Solution 


Back  Up 

Client 

Group  Owner 

Figure  1 1 .  The  Second  Iteration  of  the  Back  Up  Solution 
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2,  Automated  Persistent  Approach 

The  other  potential  approaeh  was  to  automate  the  protocol.  Automation  would 
provide  ease  of  use  and  a  seamless  Group  Owner  migration.  From  establishing  Wi-Fi 
Direct  groups  to  the  migration  of  Group  Owners,  we  automate  each  step  in  the  entire 
process.  The  first  step  is  to  automate  the  peer  discovery.  In  the  normal  protocol  this  is 
done  manually  by  selecting  a  button  on  the  user  interface.  In  our  extension,  any  device 
using  Wi-Fi  direct  would  automatically  perform  the  peer  discovery  on  start  up.  We  pre¬ 
provision  all  devices  that  are  allowed  to  form  a  network  with  the  MAC  addresses  of  the 
entire  group.  This  enables  us  to  ensure  that  unauthorized  devices  do  not  join  the  network. 

The  next  step  is  to  automate  the  group  formation  request.  Normally,  a  user  has  to 
manually  select  a  peer  from  the  device’s  peer  list  and  manually  send  the  request.  We  have 
automated  this  by  sending  the  request  to  the  first  peer  on  the  device’s  peer  list.  The 
subsequent  step  is  to  automatically  accept  the  group  request.  In  the  normal  protocol,  a 
user  would  have  to  manually  click  on  a  button  and  accept  the  request.  In  the  extended 
protocol  the  group  acceptance  is  done  automatically  without  user  interaction. 

In  our  extension  of  the  protocol,  the  first  peer  on  the  peer  list  is  selected  to  be  next 
Group  Owner.  This  does  not  have  to  be  the  case.  Criteria  such  as  battery  status,  shared 
responsibility  in  a  round  robin  fashion,  special  designation,  or  location  can  also  be  used 
to  determine  Group  Owner  selection  automatically. 

In  our  extended  protocol,  we  monitor  for  the  disconnection  in  the  network 
through  Group  Owner  departure.  Once  we  know  that  the  Group  Owner  has  left,  we  clear 
each  device’s  peer  list,  automatically  perform  a  peer  discovery,  and  begin  the  connection 
process  over.  Figure  12  shows  the  normal  timing  diagram  for  establishing  a  network. 
Figure  13  shows  the  timing  diagram  for  the  extended  Wi-Fi  Direct  protocol. 

3,  Differences  Between  the  two  Approaches 

There  are  several  differences  between  the  two  approaches  discussed  above.  In  the 

back  up  approach,  each  device  in  the  network  needs  to  maintain  the  entire  detail  about  the 

network.  Having  to  implement  this  approach  can  be  problematic  because  of  its 

complexity.  Access  to  the  Operating  System  (OS)  would  be  required  to  get  access  to  each 
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device  IP.  The  Google  API  does  not  allow  access  to  the  OS.  The  automated  approach  is 
tlie  simplest  method  to  implement  and  can  be  done  by  using  the  Google  API  Wi-Fi  P2P. 


Standard  Wi-Fi  Direct  Protocol 

Device  1  Device  2 


Manually  Start  Device  Discoveiy 


Manually  Start  Device  Discovery 

Manually  Send  a  Group  Request 

< — 

Manually  accept  Group  Request 

Device  1  Becomes  Group  owner  based  on  intent  and  Group  is  established 

Manually  disconnect  from  the  Group 

■k. 

Group  is  teiminated  and  pennanent  interruption  to  the  Network 

I 


Figure  12.  The  Normal  Sequence  for  Group  Fonnation.  It  also  Shows  the 
Peimanent  Disruption  to  the  Network,  from  [3] 
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Device  1 


Device  2 


Automatically  Start  Device  Discovery 


Automatically  Start  Device  Discoveiy 
Automatically  Send  a  Group  Request 


Automatically  accept  Group  Request 
Device  1  Becomes  Group  owner  based  on  intent  and  Group  is  established 


Manually  disconnect  from  the  Group 


Device  2 


Device  3 


Automatically  Start  Device  Discoveiy 


Automatically  Start  Device  Discoveiy 
Automatically  Send  a  Group  Request 


Automatically  accept  Group  Request 
Device  2  Becomes  Group  owner  based  on  intent  and  Group  is  established 


Figme  13.  Shows  the  Extended  Wi-Fi  Direct 
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B. 


PERSISTENT  SOLUTION  MODEL 


An  automaton  is  a  mathematical  model  of  a  computer  that  is  used  in  string 
recognition.  A  finite  automaton  (FA)  is  an  abstract  machine  used  for  string  recognition. 
FA  is  defined  as  a  5-tuple  (A,  S,  So,  Sacc,  R):  A  is  the  finite  input  alphabet,  S  are  the  finite 
set  of  states,  so  is  the  start  state  where  so  6  S,  Sacc  the  set  of  accepting  states  where  Sacc  ^ 
S,  and  R  is  the  state  transition  function  where  R;  S  x  A  ^  S.  A  Deterministic  Finite 
Automaton  (DFA)  will  be  used  to  model  the  extended  Wi-Fi  Direct  protocol.  The  state 
transition  function  does  not  allow  more  than  one  transition  from  any  state  for  a  given 
input  alphabet  symbol.  The  DFA  will  accept  a  string  s,  if  there  exist  a  path  from  a  start 
state  to  an  accepting  state  with  transitions  labeled  with  symbol  of  s  [12]. 

1.  DFA 

The  input  alphabet  or  A  is  0  and  1.  The  set  of  states  or  S,  are  So  and  Si.  The  start 
state  is  so.  The  accepting  state  or  Sacc  is  si. 


So  ^  Si 


0 


Figure  14.  Illustrates  the  State  Transition  Function. 
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a.  DFA  Definition 

State  So  is  defined  as  a  state  where  the  device  is  not  in  a  group  (disconnected).  An 
input  of  0  at  state  so  will  cause  the  device  to  loop  and  continue  to  stay  at  state  so.  An  input 
of  1  at  state  so  will  cause  a  transition  to  state  si.  State  si  is  an  accepting  state,  meaning  the 
device  has  joined  a  group  (connected).  If  at  any  point  state  si  receives  an  input  of  0,  it 
will  immediately  transition  back  to  state  So  where  it  will  continue  to  try  and  get  back  to  Si. 
The  device  would  stay  or  transition  to  state  So  anytime  it  was  not  connected  to  any  other 
device. 


C.  SUMMARY 

In  this  chapter  the  two  proposed  approaches  were  discussed.  They  were  then 
compared  to  each  other.  Furthermore,  the  automated  approach  was  selected  and  a  model 
was  given.  The  model  representation  was  of  a  DFA  state  machine.  To  conclude  a 
definition  of  that  DFA  was  given. 
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IV.  IMPLEMENTATION  AND  TESTING 


In  this  chapter  we  will  eover  the  implementation  and  testing  of  the  extended  Wi¬ 
Fi  Direet  protoeol.  The  Implementation  was  done  using  Google’s  API.  We  used  Google’s 
Wi-Direet  Demo  applieation  for  the  initial  set  up  of  the  standard  Wi-Fi  Direet  protoeol. 
The  testing  was  eondueted  using  Samsung  S3  phones. 

A,  AUTOMATION 

The  first  step  was  to  automate  the  entire  proeess  for  establishing  the  Wi-Fi  Direet 
network.  This  meant  automating  the  deviee  diseovery,  group  request,  group  aeoeptanee, 
establishing  and  re-establishing  of  the  network.  The  automation  would  allow  for  ease  of 
use,  and  establishing  and  re-establishing  of  the  network  without  any  user  interaetion. 

1.  Device  Discovery 

In  the  normal  Wi-Fi  Direet  protoeol,  the  deviee  diseovery  is  done  manually;  the 
user  has  to  manually  push  a  button  to  initiate  the  peer  diseovery.  For  our  extended 
protoeol,  we  modified  the  WifiDireetAetivity  elass.  Here  we  implemented  a  diseover 
loop  in  order  to  automatically  perform  peer  diseovery. 

2.  Auto  Group  Request  and  Accept 

In  the  standard  Wi-Fi  Direet  protoeol,  the  group  request  and  aceept  are  done 

manually.  The  user  has  to  manually  select  the  device  they  want  to  send  the  request  to  by 
pushing  a  button.  Onee  the  request  has  been  sent,  the  deviee  that  reeeives  the  request  has 
to  manually  aeeept  the  request  by  pushing  a  button.  In  order  for  us  to  automate  this 
proeess,  we  had  to  ereate  our  own  AutoConnect  elass.  This  allowed  us  to  automatically 
send  and  aeeept  requests. 

3.  Establishing  and  Re-establishing  a  Group  (Network) 

In  the  standard  implementation  of  Wi-Fi  Direet,  a  group  is  established  manually. 
Users  must  manually  perform  a  peer  diseovery  on  eaeh  deviee,  followed  by  one  user 
sending  an  initial  request.  Then  that  request  must  be  manually  aeeepted,  and 
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subsequently,  all  other  deviees  ean  join  by  sending  the  Group  Owner  a  request  to  join. 
The  subsequent  deviees  visually  identify  the  Group  Owner  by  looking  at  the  deviee, 
ensuring  they  are  sending  the  request  to  the  right  Group  Owner.  Re-  establishing  of  the 
group  is  done  manually  by  repeating  the  same,  entire  proeess.  By  Modifying  the 
DevieeListFragment,  WifiDireetAetivity  and  Auto  Conneet  elasses,  we  have  automated 
the  establishing  and  re-establishing  of  the  network  [13]. 

B.  IMPLEMENTING  THE  DFA  MODEL 

With  automation  eompleted,  the  next  step  was  to  implement  the  DFA  model  from 
Figure  16.  The  starting  state  for  a  deviee  will  always  be  at  state  So.  Also,  a  deviee  will  be 
in  state  So  anytime  it  is  not  eonneeted  to  a  Group  Owner.  Using  a  eonstant  flag  that  is  set 
when  a  deviee  is  not  eonneeted  allowed  us  to  know  when  a  deviee  was  in  state  so.  As  long 
as  that  eonstant  was  not  present,  the  deviee  would  remain  in  state  so.  Onee  state  so 
reeeived  an  input  of  1  (eonstant  was  present),  the  deviee  would  transition  to  state  si.  The 
deviee  would  remain  in  the  aeeepting  state  si  until  it  reeeived  an  input  of  0  (eonstant  was 
no  longer  present).  This  implementation  allowed  for  eontinual  monitoring  of  the  network. 
This  allowed  us  to  know  when  there  was  an  interruption  in  the  network  and  re-established 
the  network  when  needed. 

C.  TESTING 

During  the  testing  there  were  signifieant  hurdles  that  had  to  be  overeome.  There 
were  diffieulties  with  the  initial  peer  diseovery  to  establishing  and  re-establishing  of  the 
group.  After  exhaustive  testing  and  troubleshooting,  many  of  the  hurdles  were  overeome. 

1.  Testing  Configuration 

Testing  was  performed  using  Samsung  Galaxy  S3  phones  and  a  Mae  Book  Pro. 
Prior  to  any  testing  being  done,  the  Mae  Book  Pro  was  eonfigured  with  the  Android 
Development  Tool.  To  begin,  eaeh  deviee  was  loaded  with  the  Wi-Fi  Direet  demo 
applieation.  Onee  the  standard  funetionality  of  the  demo  eode  was  eheeked, 
modifieations  were  then  done  to  the  standard  souree  eode.  The  majority  of  modifieations 
were  done  to  the  elasses  that  support:  Peer  Diseovery,  Group  Formation,  and 
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Disconnecting.  Subsequently  before  each  test,  the  devices  where  loaded  with  the 
modified  Google  API  Wi-Fi  direct  application.  Each  test  ran  from  10  seconds  to  10  min 
in  length.  Initially  each  test  was  only  conducted  using  two  devices.  As  each  test  became 
more  successful,  the  number  of  devices  was  increased. 


Device 

Operating 

System 

Firmware 

Processor 

Memory 

Mac  Book  Pro 

OS  X  Yosemite 

10.10.2 

2.8GHz  Intel  i7 

16  GB 

Galaxy  S3 

Android 

4.3 

1.5  GHz  dual 

core  Krait 

32  GB 

Galaxy  S3 

Android 

4.1.2 

1.5  GHz  dual 

core  Krait 

32  GB 

Galaxy  S3 

Android 

4.1.2 

1.5  GHz  dual 

core  Krait 

32  GB 

Galaxy  S3 

Android 

4.1.1 

1.5  GHz  dual 

core  Krait 

32  GB 

Galaxy  S3 

Android 

4.1.1 

1.5  GHz  dual 

core  Krait 

32  GB 

Table  2.  Details  about  the  Devices  Used  for  Testing 


2,  Discovery  Loop 

The  initial  bug  found  during  testing  was  in  the  discover  loop.  During  the  coding 
there  was  no  delay  added  to  the  discovery  loop  to  allow  for  ample  time  to  connect.  This 
was  causing  the  devices  to  continuously  run  the  discovery  loop  causing  an  infinite  loop; 
this  did  not  allow  enough  time  for  the  devices  to  connect  to  each  other,  resulting  in 
neither  device  ever  connecting.  Upon  further  testing  a  time  delay  was  added.  The  initial 
delay  was  20  seconds.  This  allowed  enough  time  to  connect,  determining  the  shortest 

time  needed  was  the  following  test.  Decreasing  the  time  delay  from  20  seconds  to  1 

31 


second  an  ideal  time  was  found.  The  ideal  delay  was  determined  to  be  10  seconds,  this 
allowed  both  devices  enough  time  without  excessive  waiting. 

3.  Connecting 

During  additional  testing,  the  devices  would  connect  instantly  and  other  times 
would  take  up  to  10  minutes.  During  our  troubleshooting,  it  was  observed  that  this 
characteristic  was  not  present  in  the  original  protocol.  In  the  standard  protocol,  once  a 
manual  request  and  accept  messages  were  exchanged,  the  group  formation  was  almost 
immediate.  The  differences  in  the  code  from  the  original  and  extended  protocol  were  the 
automation  piece  for  the  extended  protocol.  After  extensive  testing  and  searching  it  was 
concluded  that  the  problem  was  with  the  automation  code:  after  both  devices 
automatically  performed  a  device  discovery,  each  would  simultaneously  send  a  request 
messages.  In  essence,  both  devices  were  trying  to  connect  at  the  same  time  and  therefore 
neither  would  end  up  connecting.  The  recommendation  was  to  implement  a  random 
Boolean.  This  allowed  only  one  device  to  send  a  request  message  while  the  other  sent  an 
acceptance.  The  issue  was  not  present  in  the  original  protocol  because  the  request  and 
acceptance  were  done  manually. 

4.  Re-establishing  the  Group 

Another  issue  that  had  to  be  overcome  was  re-establishing  of  the  network;  the 
amount  of  time  it  took  was  significant  compared  to  the  initial  set  up.  In  the  extended 
protocol,  before  re-establishing  can  occur,  each  device  clears  its  peer  list.  This 
implementation  was  added  because  some  devices  would  try  to  connect  to  a  Group  Owner 
that  was  no  longer  present.  After  being  unable  to  connect,  each  device  would  eventually 
connect  to  a  device  that  was  present.  This  issue  persisted  on  some  devices.  The  issue  was 
determined  to  be  the  firmware  on  the  devices.  Each  device  with  Android  firmware  4.2  or 
lower  was  unable  to  clear  its  peer  list.  This  caused  a  grater  delay  in  re-establishing  the 
network. 
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5,  Group  Owner  Identification 

An  additional  issue  discovered  during  testing  was  when  a  group  was  already 
established;  a  device  trying  to  connect  to  the  group  could  not  connect.  During  the 
automation,  when  two  devices  discover  each  other,  they  connect  to  the  first  peer  on  the 
peer  list.  This  was  successful  as  long  as  there  were  only  two  devices  present.  The  issue 
was  when  a  third  device  tried  to  perform  a  peer  discovery  and  the  first  peer  on  its  list  was 
not  the  Group  Owner;  it  would  try  to  connect  to  the  group  via  a  non-Group  Owner.  This 
would  cause  the  device  to  continually  try  to  connect  unsuccessfully.  In  order  to  address 
this  issue,  a  Group  Owner  check  was  implemented.  Before  a  device  attempted  to  connect 
to  the  first  peer  on  its  list,  it  now  checks  for  a  Group  Owner.  In  effect,  it  determines  if 
there  is  a  group  that  has  already  been  formed.  If  there  is  a  Group  Owner,  the  device 
would  connect  to  the  identified  Group  Owner,  otherwise  the  device  connects  to  the  first 
peer  on  its  list. 


6.  Dialog  Box 

A  minor  issue  was  after  a  group  has  successfully  established;  a  dialog  box  would 
remain  on  each  device  indicating  an  attempt  to  connect.  This  issue  was  only  present  in 
the  extended  Wi-Fi  Direct  protocol.  A  modification  to  the  DeviceListFragment  class  was 
made  which  forced  the  dialog  box  to  close  once  a  device  successfully  connected. 

D,  SUMMARY 

This  chapter  provides  the  details  of  the  initial  implementation  involved  in  the 
automation  of  the  protocol.  The  major  components  that  were  automated  were  device 
discovery,  group  request  and  accept  and  establishing  and  re-establishing  of  the  group. 
During  the  testing  significant  issues  were  encountered.  After  extensive  testing  and 
troubleshooting  all  of  the  issues  were  overcome. 
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V.  CONCLUSION 


The  purpose  of  this  research  was  to  extend  the  standard  Wi-Fi  Direct  protocol.  An 
initial  review  of  this  technology  found  several  issues  in  the  protocol  that  make  it  difficult 
to  use  in  practice.  The  most  significant  issue  was  the  permanent  interruption  to  the 
network  once  a  Group  Owner  leaves  the  network.  A  proposal  of  two  approaches  was 
given  to  address  this  issue.  After  careful  analysis,  we  determined  that  the  automated  and 
persistent  protocol  would  be  the  best  approach  for  our  needs.  This  approach  further 
extends  the  standard  Wi-Fi  Direct  protocol. 

The  extended  Wi-Fi  Direct  protocol  allows  for  more  robust  mobile  ad-hoc  P2P 
network  in  a  HA/DR  or  military  operations.  The  extended  protocol’s  ability  to  prevent  a 
permanent  interruption  to  the  network  has  made  Wi-Fi  Direct  persistent.  In  an  HA/DR 
environment  a  network  interruption  prevents  communications  between  first  responders. 
With  the  extended  Wi-Fi  Direct  protocol,  first  responders  can  now  keep  constant 
communications  in  a  HA  or  DR  area.  Also,  the  automation  of  the  network  formation 
eliminates  the  need  for  the  user  to  establish  a  network  manually.  This  augments  any  user 
with  out  having  to  burden  them  with  knowing  when  and  how  to  establish  the  network. 
The  ideal  use  case  for  the  extended  protocol  would  be  in  an  infrastructure  less  or  limited 
infrastructure  environment. 

Future  work  can  explore  the  development  of  the  extended  protocol,  which  has 
adapted  Wi-Fi  Direct  into  a  persistent  protocol.  Additional  research  could  be  done  to 
further  develop  the  Group  Owner  back  up  model  discussed  previously.  The  biggest 
hurdle  to  overcome  would  be  the  re-establishing  of  the  network.  Once  the  network  has 
been  interrupted,  the  back  up  model  is  no  longer  viable.  A  seamless  transition  must  occur 
in  order  for  the  back  up  model  to  be  successful. 

Transitioning  the  Group  Owner  role  without  any  interruption  is  necessary  for  this 
model  to  work.  This  might  require  a  completely  new  protocol  to  be  developed.  However, 
it  is  possible  to  modifying  the  existing  Wi-Fi  Direct  protocol.  Making  a  seamless 
transition  would  require  a  table  to  keep  track  of  all  the  devices  in  the  group.  The  table 
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would  have  information  about  each  devices  IP,  device  name  and  Mac  Address.  Also  each 
device’s  Group  Owner  intent  would  need  to  be  hard  coded.  The  table  would  then 
combine  the  device  specific  information  with  the  Group  Owner  intent  to  establish  a  back 
up  order.  Each  device  would  have  this  information  and  would  maintain  it.  One  other 
requirement  for  this  protocol  would  be  a  ping  or  heart  beat  to  the  Group  Owner.  This 
would  monitor  the  presence  of  the  Group  Owner.  If  the  ping  or  heart  beat  stops,  then  each 
device  would  know  and  the  back  up  that  is  first  on  the  table  would  take  over. 


Device 

IP 

Device  Name 

Mac  Address 

GO  Intent 

1 

I92.I68.II3.I 

Phone  I 

3EI23A 

15 

2 

I92.I68.II3.2 

Phone  2 

3DI23B 

10 

3 

I92.I68.II3.3 

Phone  3 

3PI23A 

5 

Table  3.  Example  of  What  Each  Device  Would  Have  in  the  Back  Up  Group 

Owner  2.0  Model 


In  the  example  table  above  the  initial  Group  Owner  is  phone  1 .  When  that  device 
leaves  the  group,  it  simply  gets  removed  and  phone  2  is  moved  up  and  assumes  the 
Group  Owner  role.  The  table  gets  updated  as  new  devices  join  and  leave  the  group. 
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